The present invention relates generally to the field of cloud based service environments, and more particularly to providing services in a service oriented architecture deployed in a cloud based computing environment.
A service oriented architecture (SOA) is a style of executing a computer program, or software design, where services are provided to the other components by application components through a communication protocol over a network (often the internet or a cloud network). Typical basic principles of SOA are independent of vendors, products and/or technologies. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a utility account statement online. A typical service has four properties: (i) it logically represents a business activity with a specified outcome; (ii) it is self-contained; (iii) it is a black box for its consumers; and (iv) it may consist of other underlying services. Different services can be used together to provide the functionality of a large computer program, or software application. SOA is typically less about how to modularize an application, and more about how to compose an application by integrating distributed, separately-maintained and deployed software components. SOA is typically enabled by technologies and standards that make it easier for components to communicate and cooperate over a network, especially an IP (internet protocol) network.
One implementation of service oriented architecture typical in the current state of the art is Kubernetes (commonly stylized as K8s). Kubernetes is an open-source container-orchestration system for automating deployment, scaling and management of containerized applications, including services as described above. An application or service that has been containerized is packaged with a virtualized environment for running the application, instead of requiring a virtual machine on a host computer for the containerized application to run.
Identity management, also known as identity and access management (IAM) is, in the field of computer security, a security and/or business discipline for “enabling the right individuals to access the right resources at the right times and for the right reasons.” IAM addresses the need to ensure appropriate access to resources across increasingly heterogeneous technology environments and to meet increasingly rigorous compliance requirements set forth by law in diverse geographical settings. The terms “identity management” (IdM) and “identity and access management” are often used interchangeably in the area of Identity access management. Identity-management systems, products, applications and platforms manage identifying and ancillary data about entities that typically include individuals, computer-related hardware, and software applications. IAM covers issues such as how users gain an identity, the protection of that identity, what resources that identity is allowed to access, and the technologies supporting that protection (e.g., network protocols, digital certificates, passwords, etc.).
One typical service known in the art for implementing IAM is XACML, which stands for “eXtensible Access Control Markup Language” and is a standard that defines a declarative fine-grained, attribute-based access control policy language, an architecture, and a processing model describing how to evaluate access requests according to a set of rules defined within policies. XACML is primarily an Attribute-Based Access Control system (ABAC), where attributes (bits of data and/or metadata) associated with a user or action or resource are inputs into the decision making process of whether the given user may be granted access to a given resource in a particular way. Role-based access control (RBAC) can also be implemented in XACML as a specialization of ABAC. One recognized advantage of the XACML model is that it supports and encourages separating the access decision from the point of use. When access decisions are included within the client applications (or alternatively, based on local machine user IDs and Access Control Lists (ACLs)), it is very difficult to update the decision criteria when the governing policy changes. When the client is decoupled from the access decision, such as in XACML, it is possible to update authorization policies on the fly and affect all clients immediately.
Individual services hosted within datacenters typically use rate-limiting to control the share of resources given to different tenants and applications according to their service level agreement (SLA). Rate-limiting typically limits the amount of requests for computing services that user(s) can make within a unit of time, from a geographical area and/or from a logical location(s) on a computer network. A variety of rate-limiting techniques are applied in typical datacenters, using a combination of software and hardware. Three types of rate-limiting are: (i) user rate limiting (that is, limiting a number of requests a user is making to their API key or IP—typically, if the user exceeds the rate limit, then any further requests will be denied until they reach out to the developer to increase the limit or wait until the rate limit timeframe resets; (ii) geographic rate limiting (sets rate limits for particular regions and particular time periods); and (iii) server rate limiting. Virtualized datacenters in some implementations also apply rate-limiting at the hypervisor layer if using virtual machines. Two important performance metrics of rate-limiters in datacenters are resource footprint (memory and CPU usage). These resource footprint parameter values impact scalability and precision.
Some conventional SOA service providing systems use “distributed rate limiting.” In these distributed rate limiting systems, each computer of a set of host computers for one or more services implements a distributed rate limiter protocol that shares traffic information for a given host computer to every other host computer that is part of the set, to build a consensus of traffic information and rate limits amongst a set of computers hosting the various SOA services. This type of communication between host computers is sometimes described as “gossip protocol.” If there are 8 host computers in this type of implementation, each host computer sends out 7 communications, with each communication including their rate limit information, for a total of 56 communications being sent and received (and processed) by each host computer on each round of rate limiting related communications. If there are 9 host computers, the number of communications increases to 72. If the number of host computers increases to 18, the number of communications increases to 306.